1. The Field of the Invention
The present invention relates to systems and methods for grafting the name space of one storage medium into the name space of another storage medium. More specifically, the present invention allows actions to be performed without user or program intervention when the name space of one storage medium is grafted into the name space of another storage medium.
2. The Prior State of the Art
A functional computer system generally consists of three fundamental components. The first component is computer hardware, the second component is user or application programs, and the third component is an operating system. Computer hardware generally includes such devices as a central processing unit (CPU), system memory such as RAM and ROM, mass storage such as magnetic or optical disk storage, a keyboard or other input device, and a display or other output device. Users of computer systems generally interact with user or application programs. Such programs include familiar word processing applications, spreadsheet applications, database applications, and so forth. The computer operating system performs many functions such as allowing a user to initiate execution of an application program. In addition, modern operating systems also provide an interface between an application program and the computer system hardware. Thus, while it was once common place for an application program to directly access computer system hardware, modern operating systems provide standardized, consistent interfaces that allow user applications to interface with or access computer hardware in a standardized manner.
In order to provide a consistent interface between a process such as a user application and a particular type of hardware device, there may be several software layers between the actual hardware and the process. For example, a process may make a call into the operating system. The operating system, in turn, may utilize the services provided by a hardware driver layer. The hardware driver layer then interfaces directly with the hardware. A primary advantage of such a layered approach is that layers may be added or replaced without creating a huge impact on the remaining layers. For example, if a new hardware device is added to the system, a new driver may be added, which allows the operating system to access the hardware. All these changes may take place with minimal or no impact on existing application processes.
Many operating systems provide I/O subsystems that interface with various mass storage devices. Such I/O subsystems handle many details required to translate an I/O request into actions that must be performed to fill the I/O request. Many of these actions are necessitated by the required translation from a high-level concept such as retrieving information from a file into low-level actions such as positioning the read head over a particular location on a magnetic disk and retrieving information from that particular location.
In modern computer systems, data is typically stored on mass storage devices in a hierarchical fashion with directories and files organized in a hierarchy resembling a tree structure. The location of any file or directory is typically specified by a path name. The path name typically begins with a root or starting directory and names each subsequent subdirectory until the desired file or directory is reached. For example, a file called xe2x80x9cfile.datxe2x80x9d may be stored in a directory xe2x80x9ctempxe2x80x9d which is a subdirectory of the root directory xe2x80x9croot .xe2x80x9d To access file.dat an I/O request may include a path name, either explicitly or implicitly, which directs the I/O subsystem to a particular location in order to identify and access the appropriate file. The path name for file.dat would thus be  root temp file.dat.
When the I/O subsystem receives an I/O request with an associated path name, the path name must be resolved in order to allow translation to a particular location on a particular storage device so that the I/O request can be accomplished. Path names may be directly provided to the I/O subsystem or may be constructed based on known information. Resolving file names in a file system is typically a multi-stage procedure. It generally begins with a stage that decodes all of the named components that need to be successfully identified by the file system. The procedure then continues with an iterative process of identifying, usually from left to right, the successive name components of the path name. The procedure finishes with the success or failure of each of these name resolutions. Thus, in the example above, the path name would be broken down into successive components and the resolution process would identify, in turn, the root directory, the temp subdirectory, and the file file.dat.
With the proliferation of inexpensive powerful computers, many users and organizations are assembling networks of interconnected computers that utilize local area networks (LAN), wide area networks (WAN), or other networking technologies to allow individual users to share data and information. Often these networks of computers have multiple storage devices that can be accessed by multiple users. The result is that an individual user may have access to many different storage devices. As the number of storage devices and the hierarchy of directories and subdirectories on each storage device increases, users may have an increasingly difficult time finding and managing their data.
A volume is a storage unit that may be formatted with a file system and accessed via file system paths or devices names internal to the I/O subsystem. When multiple volumes, each with a hierarchy of directories and subdirectories, are available to a user, the user may have difficulty conceptually grasping the interrelationship between the directories and subdirectories of the individual volumes. This becomes a particular problem where large amounts of data that would naturally be organized according to a particular hierarchical structure are sufficiently large to prohibit the storing and organization of all related data on a single storage volume. In such a situation, it is generally necessary to store some data on one volume and other data on other volumes. Dividing such logically related data among multiple volumes adds to the confusion and difficulty felt by some users.
To overcome some of these limitations, mechanisms have been developed to present a logical view of the storage devices that is independent of the physical organization of the data on the storage devices. These mechanisms allow the name space of one storage device to be grafted into the name space of another storage device so that a single coherent, logical view may be presented to a user.
Referring now to FIG. 1, an example of such a grafting process is illustrated. In FIG. 1, two volumes 20 and 22 are illustrated. Volume 20 and volume 22 each have independent directory structures. The directory structure for volume 20 is illustrated generally as 24 and the directory structure for volume 22 is illustrated generally as 26. As used herein, directory structure and name space will be used interchangeably to identify the names or structures of directories and files on a particular volume. Although volume 20 and volume 22 each have individual directory structures, in this example it is desirable to present a single integrated directory structure to the user as illustrated by logical directory structure 28. Logical directory structure 28 illustrates that it is desirable to graft directory structure 26 into directory structure 24 at Dir4 30. When such a grafting takes place, logical directory structure 28 results.
Although many mechanisms may be used to graft the name space of one storage volume into the name space of another storage volume, one common technology is called a xe2x80x9cmount point.xe2x80x9d A mount point is a name space location where another name space or directory structure should be mounted or grafted. Thus, in FIG. 1 Dir4 30 would be defined as a mount point. In FIG. 1 this is illustrated by dashed arrow 32. Conceptually, when mount point 30 is traversed, the file system accesses volume 22 instead of volume 20. For example, if the user is presented with logical directory structure 28, and a user wishes to access file.dat in Dir8, then the path to that file would be given as C: Dir2 Dir4 Dir8 file.dat. When the file system resolves this path name, the file system will resolve the path name to Dir4 by accessing volume 20. Once Dir4 is accessed, however, the file system would recognize Dir4 as a mount point and continue the resolution process by accessing volume 22. In essence, a mount point traditionally acts as a sort of special directory which can redirect accesses to a location in the name space of another volume.
Although mount points are capable of creating a logical organization that is unrelated to the underlying physical storage structure, some problems may still exist. For example, if volume 22 of FIG. 1 was a removable storage device, then before the device could be accessed via logical directory structure 28, the removable media would need to be retrieved and mounted. Typically these steps are performed prior to presenting the user with logical directory structure 28. Such a retrieval and mounting process may be initiated, for example, by a user via the operating system or by a program that knows the device must be retrieved and mounted prior to access. Placing the burden of retrieving and mounting a removable volume on the user or on an application process yields several undesirable results. For example, users must be trained and know how to retrieve and mount the media. If the burden is placed on the application program, then each application program that wishes to retrieve and mount removable media must incorporate such functionality. This results in a great deal of redundancy and duplicated effort.
It would, therefore, be desirable to have a system which could present a logical directory structure to a user and eliminate the need for commands such as mounting and retrieval of removable storage media that must be executed before a user or application program tries to access the removable storage media. It would also be desirable to accomplish these functions without creating duplication of effort. It is further desirable to achieve this result without requiring the user to know how to retrieve and mount removable media.
The foregoing problems in the prior state of the art have been successfully overcome by the present invention, which is directed to a system and method for performing arbitrary actions when grafting all or part of the name space of one storage medium into the name space of the same or another storage medium. The present invention may be used to implement a wide variety of systems and achieve a wide variety of results. For example, when a mount point is traversed, the operating system may automatically retrieve and load the appropriate media before completing the I/O request. The present invention is robust enough to allow any arbitrary action to be performed when a mount point is traversed, even actions which are not normally associated with an I/O system or an I/O request.
The present invention provides an active mount point driver. This driver may be apart of the I/O subsystem of the operating system. When an I/O request is received that includes a path or file name, the path and file name is resolved in the traditional manner. If during the resolution process an active mount point is encountered, control is turned over to the active mount point driver. The active mount point driver may then take any action that is necessary in order to further completion of the I/O request. Once the active mount point driver has completed or initiated any desired actions that need to occur before the I/O request is complete, control may then be turned back over to the other components of the I/O subsystem for completion of the I/O request if the I/O request has not been completed by the actions of the active mount point driver.
In performing its actions, the active mount point driver may make use of a wide variety of system resources, processes, drivers, and the like. Once control is turned over to the active mount point driver, the active mount point driver may have access to all resources, processes, drivers, subsystems, and so forth of the system. If the system is networked or connected to other systems, then the active mount point driver may have access to those systems and any components, subsystems, processes, drivers, and the like associated with those systems. The structure defined by the present invention is robust enough to allow the active mount point driver to take whatever action is desired when an active mount point is encountered.
As one example of the capability of an active mount point, it is possible to develop and display to a user a directory hierarchy that integrates all CDs in a CD jukebox. A user wishing to access a particular CD would simply select the appropriate location in the directory structure. As the I/O system begins to resolve the path name to the CD, one or more active mount points can be encountered. These active mount points can, among other things, turn control over to the active mount point driver which can then issue commands to the CD jukebox to select and load the appropriate CD. Control may then be turned over to the I/O subsystem for completion of the I/O request. If the CD contains music, the active mount point driver may also issue commands to a multimedia subsystem to begin playing the CD once the CD has been mounted. Any other actions are also available when an active mount point is encountered.
Many mechanisms may be used to implement the system just described. Some important features are the ability to identify an active mount point and the ability to turn control over to the active mount point driver when an active mount point is encountered. The mechanism for making the transition should be efficient and provide for control to be returned from the active mount point driver if needed once the active mount point driver has completed the actions it is to perform. Additionally, when control is turned over to the active mount point driver, the active mount point driver must be able to identify or select which actions are to be taken. As explained in greater detail below, when deciding or selecting what actions should be completed the active mount point driver may gather other information from other sources or may turn control over to other drivers or processes to make those decisions. One embodiment of the present invention utilizes additional information stored with the mount point to achieve some of these functions.
In many systems, a directory or file may be viewed as a collection of different properties or attributes. Some common attributes for files are the name attribute, various flag attributes such as system, read-only, hidden, and the like, and a data attribute to store data. Some common attributes of directories are the name of the directory, possibly some security information, pointers or other mechanisms to identify the directories or files contained by this directory, and so forth. One embodiment of the present invention creates an active mount point by adding an additional attribute to a directory or file. When the directory or file is encountered during an I/O request, the I/O subsystem can identify the additional attribute and recognize the directory or file as an active mount point. Control may then be passed to the active mount point driver for further processing. The active mount point driver may retrieve information from a variety of sources, including one or more attributes of the directory or file. Based on this information, the active mount point driver may decide what action should be taken. Once the active mount point has completed its work, control may then be returned to the I/O subsystem for further processing.
The active mount point attribute may be added to both files and directories. The attribute is preferably additive in nature so that individual files and directories may be either be active mount points or not, depending upon the status of the active mount point attribute. An active mount point attribute preferably has both a tag and a data value. The tag is used to identify the active mount point driver that is the xe2x80x9cownerxe2x80x9d of the active mount point. In general, the owner of the active mount point is responsible for processing either all or part of an I/O request involving the active mount point. This structure allows multiple active mount point drivers to reside in a single system, each adapted to achieve different purposes. The data value of the active mount point attribute is stored in the active mount point attribute by the owner. Thus, an owner may use the value of the active mount point attribute to store any data that will be necessary or helpful to complete a particular I/O request that involves the active mount point. Such a data value may contain all information necessary to make decisions about what actions should be taken, or may contain pointers or other information that allows the active mount point driver to locate the information necessary to make a decision as to what action should be taken. The value of the active mount point may also identify other software entities that should be used to make the decisions as to what actions should be taken. In essence, since the value of the active mount point attribute is controlled by the owner, the owner can store any desirable information in the active mount point.
One embodiment of the present invention utilizes an I/O system having a plurality of layered drivers. The active mount point driver forms one of the layers of the I/O system. When an active mount point attribute is identified by a particular driver, the driver extracts the tag and the value of the active mount point. The I/O request, along with the tag and the value of the active mount point, is then passed to other of the layered drivers until one identifies itself as the owner of the active mount point. The owner then takes control and resumes processing the I/O request. The owner of the active mount point may completely process an I/O request, or may make use of other drivers, resources, information, processes, and the like to completely process the I/O request. In certain situations, the owner may also make use of other computers or systems to completely process the I/O request.
Because each active mount point has both a tag and a value, the active mount point mechanism provides an extremely flexible structure which may be used by any number of drivers to achieve any number of functions. An example of a system that automatically loads and mounts removable media has already been given. As another example, the active mount point may take actions not normally associated with an I/O system. For example, active mount points may be used to implement a secure file system which grafts the name space of files stored in a secure physical facility into a large directory hierarchy. When an individual accesses one of the secure files, control may be turned over to the active mount point driver. The active mount point driver may then initiate special validation procedures to determine whether the individual attempting to access the file has the authorization to do so. For example, the active mount point driver could initiate a separate challenge to the individual attempting to access the file. The active mount point driver may also send an email or other message to a security location notifying them that a certain individual was attempting to access the file. If the file is only allowed to be accessed during certain times or on certain days, the active mount point driver may check the date and time to determine whether access to the file is to be allowed. As seen by this example, an active mount point driver may take any number of actions based on information either directly available or that is accessed or obtained.
As a final example, utilizing the present invention it is possible to graft things into the name space of a storage device that traditionally could not be grafted into the name space of a storage device. For example, mount points have traditionally been used to graft the file system name space of one mass storage device into the file system name space of another mass storage device. With the present invention, however, it is possible to graft a non-file system name space, such as Internet or intranet web sites into the name space of a mass storage device. The Internet could be represented in the user interface by a special icon by supplying information from the active mount point to the user interface. When the user attempted to open the icon, the active mount point driver would create access to the Internet or other data provider and offer feedback on the content available through the data provider to the user via the user interface. As illustrated by the above examples, the present invention provides an extremely robust mechanism to allow arbitrary actions to be performed when grafting the name space of one device into the name space of another device.
Accordingly, it is a primary object of this invention to provide a system and method for performing arbitrary actions when the name space of one device is grafted into the name space of another device. It is another object of this invention to provide a system and method for performing these actions transparently to the user in order to reduce the amount of knowledge a user must possess to access certain devices or information from those devices. A still further object of the present invention is to provide a system and method that is extensible to situations not envisioned by the initial architects.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.